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ABSTRACT 



A system and method of controlling a computer network to 
obtain information needed to render risk evaluative deci- 
sions from vendors in real time. The information may be 
obtained for agents preparing insurance applications or for 
an automated application processing system. Agents or 
automated appHcation processing systems require access to 
an external vendor to obtain information about a customer, 
such as car accident or credit records. The request for data 
must be formatted to be read by the vendor system, which 
sends the responding data in real time. This responding data 
is forwarded to the requesting party for further processing of 
the application. 

14 Claims, 5 Drawing Sheets 
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METHOD AND APPARATUS FOR in real time or aear real time to risk evaluators or to 

OBTAINING DATA FROM VENDORS IN automated risk evaluation processes. 

REAL TIME Systems and methods consistent with the present inven- 

I. RELATED APPLICATIONS tion control a computer network to assemble data for ren- 

TOs application is a continuation-in-part of U.S. patent ' ^^'^^ ^^^^^^^^^ data the network including a 

application Ser. No. 09/153,155 nied Sep. 15, 1998 which is ^^^^ manager having a memory, and a data gathermg system 

a continuation of U.S. patent application Ser. No. 08/569, coupled to vendors of data. The data manager processes 

615 filed Dec. 8, 1995, now U.S. Pat. No. 5,809,478, which requests for data by invoking real time information interface 

is related to U.S. patent application Serial No. 08/374,484, processes to retrieve the needed additional data through the 

filed Jan. 17, 1995, aU of which are incorporated herein by data gathering system. The data gathering system formats 

reference. the request using templates based on the data vendor to be 

n. BACKGROUND OF THE INVENTION accessed TTie data vendor is sent the foimatted request and 

returns the requested data m real time. The data gathenng 
The present invention relates generally to computer system matches received response data with the request and 
decision-making systems, and m particular to the use of 15 delivers the data to the data manager for further processing, 
computer networks to gather information relevant to , , , , . „ 
insurance-related decisions. embodiment, the data manager automatically pro- 
Insurance companies issue policies to insure against dif- cesses applications and generates requests for data when 
ferent types of risk. The amount they charge for such ""^^^^^ P^^^^"^ automatic nsk evaluation, 
policies should accurately reflect the risk insured against so 20 ^"^^^ foregoing general description and the following 
the companies can offer profitable, but competitively priced, detailed description are exemplary and explanatory. They 
policies. Thus, accurate risk evaluation is essential for such provide further explanation of the invention as claimed. 

companies to make rational business decisions. 

T.-, . n -1 1 ^ Au A IV. BRIEF DESCRIPTION OF THE DRAWINGS 

Histoncally, nsk evaluation was performed by underwnt- ^t.^xv^i^^^ *^i.^v^*v x ^ ^ *v 

ers who are individuals with expertise in assessing risk 25 The accompanying drawings, which are incorporated in 

based on many factors. These underwriters, or "risk and constitute a part of this specification, illustrate several 

evaluators/' work in conjunction with insurance agents to embodiments of the invention and, together with the 

coUecl and analyze data representing factors affecting the description, serve to explain the objects, advantages, and 

risk associated with a particular customer. principles of the invention. 

Of course, the accuracy of the risk evaluation depends 30 in the drawings* 

upon the accuracy of the data forming the basis for the ^ ^ ^ y^^^ ^. .^^^ ^^^^^ 

evaluation. Traditionally, thjs data, such as driving records ^^^^^ information according to the present 

credit records, and name and address records, was acquired ^vention* 

from independent sources with their own formats and „^ « , , . . . 

request requirements. The coHeclion of this data and the 35 . ^ ^ flow chart depicting the steps for requesting 

necessary conversions between incompatible formats has insurance mformation from outside vendors; 

proven expensive and burdensome. With the automation of FIG. 3 is a flow chart depicting the steps for obtaining and 

risk evaluative decision-making, this expense and burden returning the requested information; 

has only increased. FIG. 4 is a flow chart of the steps for automatically 

At the same time, customers are increasingly seeking 40 processing an application; and 

agents able to handle all transactions knowledgeably and piG. 5 is a communications diagram showing the data 

efBciently, anticipating future needs, and delivering core solutions transaction manager of FIG. 1 as configured for 

benefits expeditiously. Current systems, however, hamper automated application processing, 
efforts to achieve these goals. Agents are given limited 

access to information, and an unnecessarily large number of 45 V. DETAILED DESCRIPTION OF THE 

transactions are referred to the underwriting environment. PREFERRED EMBODIMENTS 

As a result, risk evaluators often spend an excessive amount r -n u j • j * -i * »u . 

r - J- J 1 - 1 ^ ^- • Reference will now be made in detail to the construction 

of time on mdividual nsk selection, rather than on assisting ^ r- i ^ • . -.l 

, . , , 1 , ^ V and operation of implementations consistent with the present 

agents in broader market management activities. . j - • a - t *u 

^ ^ 1 , ■ . crs invention illustrated m the accompanying drawmgs. In those 

To reduce overhead, insurance companies now use com- so ^^^^ ^^^^^^^^ operations are designated with 

puter systems to help nsk evaluators perform their assess- reference numerals where possible, 

ment. These systems facihtate communication between risk ^ , . , - - , , 

evaluators and agents, improve the speed and accuracy with . Systems and methods consistent with the present mven- 

which insurance policies are processed, and increase the •i"" ^l"'^ ^ msur^ce agent or mtomaUc apphcation 

overall quaUty of the insurance product purchased by con- 5S processes to obtam mformaUon needed to process a custom- 

sumers ^ apphcation for insurance. Information on customers 

T r • r * • may be available at external vendors, such as individual state 

In spite of the mcreasmg use of computers, insurance j /u *u . i „ ■ <r *- u * * i 

. y rr. . • ^-iTi- J • \ . databases, that nst information about potential customers 

companies efficiency is still limited. Prior agent computer , • j . • r ji-r .5 -r x- r™ 

r * 1* such as accident mformation and life status mformation. The 

systems requested mformaUon from external systems about ^ .^^^^^^^^ ^^^^^ information in 

a potential insurer using a batch processing network, such as ^ , ^ , j j * • *u 

Z n-- j^ .u- real time from the cxtcmal vendors and returnmg the same 

an oveniigbt batch exchange. Pnor insurance data gathenng ,^ ^ automated process or the agent to allow for faster 

systems did not allow for real-tune or near real time gath- v x- . ^ 

. c J, . c r . • I msurance apphcation processmg. 

enng of data for faster insurance evaluation. i-r r e> 

III. SUMMARY OF THE INVENTION ^5 A. Data Retrieval 

The present invention facilities risk evaluation using FIG. 1 is a block diagram 100 illustrating the general flow 

information sources that gather and return data on insurers of data-retrieval and decision-making processing according 
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to one embodiment of the present invention. The present 
invention uses a computer network to retrieve and assemble 
customer data for use in rendering decisions based on that 
data. 

As FIG. 1 shows, there are four sources of requests for 5 
customer data: agents at terminals 110, risk evaluators at 
terminals 112, operations personnel at terminals 114, and 
data solutions transaction manager (DSTM) 140. All four 
sources may require information from external data sources 
to evaluate a potential insurance customer. The sources 10 
transmit their requests for such information via DSTM 140 
to a data gathering system (DGS) 120 that accesses external 
sources of information known as information vendors 125. 
DSTM 140 and DGS 120 both include a processor and a 
memory. 15 

There are several types of information vendors 125. For 
example, one information vendor may be a state agency 
providing motor vehicle records for the citizens of that state. 
Another information vendor may provide credit reports for 
customers nationwide. ^ 

Data requests are made by agents at terminals 110, risk 
evaluators at workstations 112, and operations personnel at 
terminal 114 by sending the request to data solutions trans- 
action manager (DSTM) 140 either directly, through a token 
ring, or through transporter 135. DSTM 140 also generates 
data requests when perfonning automatic application pro- 
cessing. DSTM 140 formats data requests and forwards 
them to DGS 120. 

DSTM 140, using data manager 150, maintains customer 
data in data repository 160. All data gathered on a customer 
is stored in the data repository 160 so that when additional 
requests are made for the same data, the data may quickly be 
obtained without requesting it from vendors. 

B. Processing of Data Requests 

Consistent with the present invention, agency computer 
130 provides agents with a user interface on terminals 110 
for displaying policy information and decisions, and enables 
the agents to interact with DSTM 140 through transporter 4q 
135. The user interface allows an agent to enter customer 
data into prequalification policy templates and update exist- 
ing policy files, to display decision results to agents and 
allow them to enter customer data requests and changes to 
policy data, and to order any available data for a particular 45 
customer from participating information vendors. 

Once an agent at agent terminal 110 completes the 
templates, agency computer 130 formats the customer data 
into policy records and transmits these files to DSTM 140. 
DSTM 140 sends risk evaluative decisions back to agency 50 
computer 130 through either batch processing or real-time 
links through transporter 135. Agency computer 130 then 
enters each policy into a queue associated with the agent 
handling that policy. 

FTG. 2 contains a flow chart 200 depicting information 55 
processing flow for requests for data. Although this figure 
refers to an agent making a request for information, requests 
may also be made from terminals 112, 114, or DSTM 140. 
An agent enters a transaction request in a template on agent 
terminal 110 (step 210). The transaction request includes an 60 
indication of whether the agent wants the request processed 
in real time or tising batch processing. Transporter 135 
forwards the transaction to DSTM 140 (step 220). DSTM 
140 confirms the identity of the agent using an agent 
identifier and prepares a request record that includes an 65 
indication of whether the request should be processed in 
real-time or batched (step 230). Data repository 160 holds an 
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archive of previous data requests for each customer and 
stores the resulting data found for each request. When a 
request is received DSTM 140 searches data repository 160 
to determine if the information requested already exists in 
the data repository 160 (step 235). If so, the DSTM 140 
forwards the requested data to the requester without notify- 
ing DGS 120 of the request (step 240). Otherwise, the 
request is archived in data repository 160 for purposes of 
later matching it to results of the request (step 245). DSTM 
140 connects to DGS 120 and forwards the request (step 
250). DGS applies a series of templates to reformat the 
request depending on the vendor to be queried for the data 
(step 255). For example, if the information available for 
households in the State of Texas is limited to motor vehicle 
records and credit reports, a template wiU be applied to a 
request from Texas which will limit the information obtained 
to those two categories regardless of the request made by the 
requester. Depending on the information requested and the 
state or region involved, the customer data request must be 
formatted to comply with the requirements of a particular 
information vendor. For example, a motor vehicle record 
request to the State of Texas must be formatted differently 
from a request to the State of Illinois. Similarly, a credit 
report request maybe formatted differently depending upon 
the vendor involved. 

DGS 120 determines whether the request is a real-time 
request or a batch request (step 260). If a batch request, DGS 
120 stores a group of batch requests in a batch group (step 
270). DGS 120 obtains information ftom information ven- 
dors 125 for responding to the batch requests periodically 
(step 280). DGS 120 returns any resulting data obtained 
from the information vendors 125 to DSTM 140 for storage 
in the data repository 160 and distribution to the correspond- 
ing agent terminal 110 (step 290). 

FIG. 3 is a flowchart showing the steps 300 for processing 
a real time request. After DGS 120 determines that a request 
is interactive (step 260), DGS 120 forwards the request to 
the information vendors 125 (step 310). After sending the 
interactive request, DSTM 140 awaits a return call from 
DGS 120. DSTM 140 monitors whether the return call is 
received within a predetermined time period (step 330). If 
not, DSTM 140 sends a message to the corresponding agent 
at agent terminal 110 stating that the data requested is 
unavailable (step 340). If DSTM 140 receives the return call 
from DGS 120 within the time period, DSTM 140 turns off 
a timer that measures the predetermined time period (step 
350). DSTM 140 retrieves the data from the call received 
fi-om DGS 120 (step 360). DSTM stores the response in the 
archive in data repository 160 along with the request (step 
370). DSTM 140 formats the data for viewing by the agent 
and forwards the formatted data to the agent at terminal 110 
via transporter 135 (step 380). In addition to routing the 
received data response, DSTM 140 creates a consolidated 
insurance profile (step 390). This consolidated profile is a 
uniform compendium of all external data retrieved for a 
particular policy household. The consolidated profile is 
dynamic in that it can be automatically updated each time 
requested information is returned. This consolidated profile 
may also be viewed at any time by risk evaluators or 
operations personnel. 

C. Automated Data Requests 
FIG. 4 is a flow diagram 400 iQustrating the general 

process flow of an automated customer data request carried 

out at DSTM 140. 
Prior to the automated request, insurance agents provide 

the primary human contact with potential policy holders and 
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obtain customer data pertinent to the desired policy. For 
exacDple, in an automobile insurance policy, this customer 
data may include the driver's age, the type of vehicle to be 
insured, and the driver's driving history. An agent enters this 
data into an agent terminal linked to the agency computer 
(step 410). In response, the agency computer creates a policy 
record containing this data, and assigns the record a unique 
identification number (step 415). 

Before understanding the remaining flow, it is helpful to 
understand the three stages of policy analysis under auto- 
mated processing. First, policies undergo Prequalification 
Business (P.B.) analysis. If a policy is not rejected during 
this stage of processing, the policy is further analyzed in a 
second stage of analysis prior to issuance. Finally, in a third 
stage, existing policies undergo periodic renewal analysis. 

Preferably, the agency computer sends policy records 
intended for analysis into DSTM 140 (step 420). DSTM 140 
builds a case file corresponding to each submitted policy 
record (step 425), 

When a case file is built, a work flow manager process 
operating within DSTM 140 directs the case file through a 
series of processes designed to perform risk assessment. 
Usually, the system first evaluates a case file to determine 
what information is needed to perform risk assessment 
properly. DSTM 140 uses an expert system engine to 
perform a series of complex pattern matchings using "pro- 
files" of information needs (step 430). Profiles are combi- 
nations of criteria used to render a decision about customer 
data. 

The expert system determines the information needed 
based on any successful profile matches (step 435). Then a 
work flow manager forwards the case file, as well as an 
indication of the needed information, to an information 
interface process included within DSTM 140 (step 440). 

The information interface process sends customer data 
requests to DGS 120, to external sources of information, 
such as information vendors 125 as described in FIGS. 2 and 
3 (step 445). DGS 120 sends data responding to the request 
to the information interface at DSTM 140 (step 450). The 
information interface of DvSTM 140 automatically updates 
the case file with the retrieved information, and the work 
flow manager then directs the case file back to the risk 
assessment process. 

The same expert system engine that determined what 
information was needed also performs the actual risk evalu- 
ation. The expert system matches the data in the case file to 
a series of risk evaluation profiles to determine the quality of 
the risk, to classify the risk correctly, and to generate advice 
for an agent (step 455). If possible, the expert system then 
renders a decision to accept or reject the policy according to 
the profile matches, and sends the agency computer the 
policy record and decision (step 460). 

Depending on the decision made during risk assessment 
and the information returned to the agency computer, the 
agency may resubmit a policy several times for further data 
retrieval and risk evaluations (step 465). 

In the preferred implementation consistent with this 
invention, the agency submits policies to DSTM 140 for 
final risk evaluation before issuing the poHcy. The final risk 
evaluation reevaluates the policy in light of any last minute 
changes made by the agency. 

To perform this final evaluation, policies are communi- 
cated from the agency computer to DSTM 140. After the 
case file is rebuflt (step 470), the expert system matches 
information needs profiles with the case file (step 475). If 
additional information is required, DSTM 140 invokes the 
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information interface processes to retrieve such information 
using DGS 120 (step 480). Finally, the expert system again 
matches risk evaluation profiles to the case file to render a 
decision (step 485). 

If the expert system approves the policy during the second 
risk evaluation (step 490), the policy is automatically sub- 
mitted for issuance (step 495). If the expert system rejects 
the policy, the rejected policy is directed to a risk evalnator 
workstation for review by a risk evaluator (step 498). The 
risk evaluator may then decide to confirm the decision 
rejecting the policy, or decide to accept the policy notwith- 
standing the previous decision to reject. 

FIG. 5 is a communications diagram 500 showing DSTM 
140 as configured for automated application processing. 
Under automated risk evaluation, agency computer 130 
sends policies 520 to DSTM 140 via transporter 135 for 
processing. 

A work-in-progress (WIP) database 545 stores the policy 
information in relational database tables. Each table stores a 
particular piece of data for a policy and is indexed by the 
unique case or policy number associated with that piece of 
data. Thus, one particular table may store the zip codes for 
each policy. Several other relational database tables, not 
shown in FIG. 5, store profiles, statistics, and other data used 
by DSTM 140. Once a policy is placed in the WIP database 
545, a status of the policy is set to "active." 

Work flow manager process 550 directs the processing of 
active polices and the execution of most processes within 
DSTM 140. Work flow manager process 550 accesses WIP 
database 545 and selects afl active cases for processing. 
Workflow manager 550 routes active cases through infor- 
mation needs identification (INI) subproccss 555, obtain 
case information subprocess 556, information reconciliation 
subprocess 557, risk evaluation subprocess 558, risk evalu- 
ator review subprocess 559, and complete case subprocess 
560. 

INI subprocess 555 determines the information needs 
using the same knowledge base decision-making process as 
is employed for risk evaluation. The difference is that 
decisions rendered through INI subprocess 555 concern the 
information required to render risk evaluations, nut the risk 
evaluations themselves. The different results arise because 
the processes use different types of profiles. The decisions 
result from matching those profiles to the case information. 

Obtain case information subprocess 556 executes infor- 
mation interface processes to gather all internal and external 
data that INI subprocess 555 determined to be required. 
Once this data is gathered, subprocess 556 updates the 
policy file in WIP database 545. 

Information reconciliation subprocess 557 reconciles 
cases needing external data that are placed in a "pended" 
status in the WIP database 545 until the external data is 
received. Information rcconcUiation subprocess 557 recon- 
ciles the initial customer data provided by the agency with 
the data obtained in obtain case information subprocess 556. 
If the two sets of data cannot be reconciled, the knowledge- 
base engine nevertheless renders a decision, and DSTM 140 
transfers the case back to agency computer 320 for further 
processing. This agency processing, called data "scrubbing," 
reconciles conflicting data. Following data scrubbing, 
agency computer 130 resubmits the case for evaluation by 
DSTM 140. 

Risk evaluation subprocess 558 is performed by the 
knowledge base engine to determine a risk if possible for the 
policy. The policy may also be sent to a risk evaluator for 
review 559. Complete case subprocess 560 forwards a 
completed case to the initiating agency computer 130, 
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D. Conclusion 



Accordiagly, the systems and methods consistent with the 
present invention provide a faster system and method for 
retrieving data for either manual or automatic risk assess- 
ment. 

It will be apparent to those skilled in the art that various 
modifications and variations can be made in the disclosed 
process and product without departing from the scope or 
spirit of the invention. Other embodiments of the invention 
will be apparent to those skilled in the art from consideration 
of the specification and practice of the invention disclosed 
herein. The specification and examples are exemplary only. 
The true scope and spirit of the invention are defimed by the 
following claims. 

What is claimed is: 

1. A method of controlling a computer network to 
assemble data for rendering decisions based on the data, the 
network including a data manager having a memory, and a 
data gathering system coupled to vendors of data, the 
method comprising the steps, performed by the data 
manager, of: 

processing a request for data to evaluate an application; 
and 

invoking real time information interface processes to 
retrieve needed additional data through the data gath- 
ering system, the step of invoking including the sub- 
steps of 

applying a series of templates to the request, 
formatting the request according to the data vendors, 
sending formatted request to the appropriate data ven- 
dors for real time processing, 
receiving data from the data vendors in response to the 

formatted request in real time, 
matching the received data with the request, and 
delivering the matched data to the data manager. 

2. The method of claim 1 further including the steps of: 
archiving the request at the data manager; and 
corresponding the matched data at the data manager with 

the archived request. 

3. The method of claim 1 wherein the invoking step 
further includes the step of: 

storing data received from the vendors in the archive file. 

4. The method of claim 2 further including the step of: 
checking the archive for the requested data before invok- 
ing the information interface processes. 

5. The method of claim 1 further including the step of: 
determining whether the data gathering system returns 

matched data within a predetermined period of time. 

6. The method of claim 5 further including the step of: 
informing the requester that the requested data is unavail- 
able when the matched data is not returned within a 
predetermined period of time. 
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7. The method of claim 1 wherein the step of processing 
a request includes the substeps of 

automatically processes applications, and 
generating the request for data when needed to process an 
application. 

8. A system for assembling data to render decisions based 
on the data, the system including: 

a data manager having a memory; 
means for processing a request for data to evaluate an 
application; 

a data gathering system coupled to vendors of data; 

means for invoking real time information interface pro- 
cesses to retrieve needed additional data through the 
data gathering system; 

means for applying a series of templates to the request; 

means for formatting the request according to the data 
vendors; 

means for sending formatted request to the appropriate 

data vendors for real time processing; 
means for receiving data from the data vendors in 

response to the formatted request in real time; 
means for matching the received data with the request; 

and 

means for delivering, the matched data to the data man- 
ager. 

9. The system of claim 8 further including: 

means for archiving the request at the data manager; and 
means for corresponding the matched data at the data 
manager with the archived request. 

10. The system of claim 9 wherein the means for invoking 
further includes: 

means for storing data received from the vendors in the 
archive file. 

11. The system of claim 9 further including: 

means for checking the archive for the requested data 
before invoking the information interface processes. 

12. The system of claim 8 further including: 

means for determining whether the data gathering system 
returns matched data within a predetermined period of 
time. 

13. The method of claim 12 further including: 

means for informing the requester that the requested data 
is unavailable when the matched data is not returned 
within a predetermined period of time. 

14. The method of claim 8 wherein the data manager 
includes: 

means for automatically processing applications, and 
means for generating the request for data when needed 
to process an appUcation. 
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